Аналитический мир огромен и неоднороден. Нас разделяют расстояния, разница во времени, в культуре, языковый барьер. Но, ничто не разделяет нас так, как приверженность к различным подходам. Главный водораздел проходит между двумя, порой, непримиримыми лагерями: приверженцами классического подхода и приверженцами идеологии Agile. Кто же из них прав? Под чьи знамена встать, что бы не ошибиться в жизненном выборе? А нужно ли вообще выбирать? Данный доклад - это результат долгого спора с поклонниками и оппонентами этих двух полярных подходов. В докладе будет рассказано, что существуют вполне понятные и формализованные признаки проекта, анализ которых и позволит нам выбрать наилучший подход для каждого отдельного проекта.

мастер класс

Кумсков ЛАФ-2014

Системный подход: Модель Предметной области, модель Бизнес-системы и модель Информационной системы – строим вместе.

На мастер классе будет разобрана три примера (за 90 минут) - один пример показывается по шагам на слайдах. Строятся три модели: модель ИС (прототип модели сценариев использования), модель бизнеса (прототип модели бизнес сценариев использования) и модель предметной области. Второй и третьи примеры слушатели строят в группах по 3-5 человек и публикуют на листах флип-чарта (развешанных на стенке), затем проводится «разбор полета». Мастер класс показывает внутреннюю взаимосвязи и синергию трех представлений задачи – трех моделей.

При создании программного обеспечения нередко возникает непонимание между различными группами заинтересованных лиц (заказчиками, аналитиками, разработчиками и другими). Это неизбежно вызывает расхождение между пожеланиями заказчика и готовым продуктом. Особенно много недоразумений обычно связано с реализацией, т.к. для участников проекта, не являющихся программистами, код представляет собой ‘чёрный ящик’ и почти не поддаётся контролю.

Что системному аналитику делать с чёрным ящиком? В докладе рассматриваются некоторые приёмы, способствующие организации эффективного взаимодействия с разработчиками.

Нет предела совершенству! И как только более-менее стабилизируется процесс разработки требований, начинаются вопросы - а что же делать, если требования меняются? Такой вопрос возникал и у меня на разных проектах. В ходе размышлений и опытов родился некоторый подход, которым хотелось бы поделиться и развить с учетом мнения коллег в ходе этого доклада.

Вопросы:

1) постановка задачи: какие же проблемы мы хотим решить?

2) варианты реализации управления изменениями: в рамках одной версии, в рамках нескольких версий

3) цикл жизни артефактов проекта - а за всеми ли изменениями нужно следить?

В целом доклад базируется на моем вебинаре https://www.webursitet.ru/article/versionirovanie-trebovanii--zapis-vebinara.html , поэтому буду рада вопросам, которые покажут, в какую сторону надо развить тему.

Постановка задачи

Ну вот кто с этим не знаком? Нужно там, ну не знаю, сервис на мобилу подключить. Лезешь на портал, а там просят указать что-то, что-то такое эдакое ради чего ты должен приехать в офис любимого поставщика услуги. А мобильный кабинет понятия не имеет о твоей персональной информации, которую ты на портале уже указал. Офис находится у черта на рогах… Звонишь в поддержку — и понеcлась:

«Ваш звонок очень важен для нас, оператор освободится через 10 минут, очередь — 20 входящих»,

«Ой, у нас нет вашего письма»,

«Нет, ну вы нам не писали, нет заявки»,

«Я не могу Вам ответить, сейчас соединю со специалистом»,

«Кто, я в этом специалист? чо они там несут??? звоните им снова и пусть Вас пошлют наконец-то туда, куда надо»

и т. д., и т. п.

И вот если отбросить уголовно наказуемые желания по отношению к тем, кто все это придумал, остается одно: глядя этим людям в глаза спросить — ну как так вышло, что вышло ну никак?

Уверены, что это не со зла. И задумка то была благородная, и на бумаге все срасталось. Но почему в жизни-то не работает? Как сделать так, чтобы все были довольны? Чтобы и бизнес пёр, и клиенты были счастливы? На какой баррикаде подружить эти две стороны одной медали? Кто и как их должен подружить?

По-хорошему, услуга должна оправдывать ожидания пользователя и всячески его радовать тем, что она:

• Не создает проблем, а помогает их решать
• Не грузит необходимостью делать лишние действия и получать результат за минимум шагов
• Не запрашивает информацию, которая уже была предоставлена ранее (в т. ч. в других каналах)
• Проста и удобна на каждом этапе взаимодействия
• Обеспечивает непрерывность (бесшовность) перехода от шага к шагу, т. е. барьеров должно быть мало, а лучше чтобы их не было вовсе
• Доставляет радость и побуждает к повторному использованию

Не, ну вы конечно скажете — тут UX нужен. А факт ли? Положим, есть инструменты, позволяющие спроектировать удобную для клиента услугу. Один из наиболее эффективных — это Customer Journey Map (CJM).

Но хватит ли UX дизайнера для проектирования того, что на самом деле представляет собой замес из бизнес-процессов, оргструктуры, программно-технических средств, котрый нужно повернуть к Клиенту правильным лицом? Ведь почти все это — вотчина бизнес-аналитика. Только по ходу он не шибко с этой задачей справляется.

Где золотая середина? Как сделать так, чтобы все были счастливы?

Вот об этом предлагаем и поговорить.

Что будет

Целью воркшопа является ознакомление слушателей с теоретическими основами CJM и получение практических навыков ее разработки.

В теоретической части будет раскрыта общая идея CJM, показаны подходы к ее разработке, даны рекомендации по формату представления CJM. Кроме того, будет уделено внимание зависимостям между бизнес-анализом и проектированием CJM.

В практической части участникам воркшопа будут предложены задания по проектированию новых сервисов или оптимизации существующих. Результаты выполнения практических заданий будут вынесены на коллективное обсуждение.

Заключение

В результате участия в воркшопе участники получат в свою копилку ещё один инструмент, который поможет более системно подходить к локальным улучшениям и видеть не только разрабатываемое ПО, но и услугу (а то и весь бизнес) вокруг этого ПО.

1. Все лгут

2. Где брать информацию?

3. Чему доверять?

4. Что делать с недостоверными данными?

5. Когда нужно, чтобы информация достоверной?

Основные тезисы доклада:

1. Проблема: заказчик не всегда осмысленно участвует в сборе требований.
2. Почему так получается?
3. Как убедиться, что все хорошо и заказчик понимает о чем вы написали?
4. Зачем добиваться понимания требований заказчиком

• В чем выгода исполнителя.
• Чем такой подход лучше заказчику.
• Дополнительные бонусы.